So I might be missing something here, but it does seem to me like the parsing packages Golang provides would indeed be able to differentiate type alias from the underlying type, as shown by my proof of concept in the linked issue. Although I wonder if the issue is that the types.TypeName passed to getPackageScopedType was resolved to the real type farther up the call stack.

The types package clearly understands the difference between alias and types: https://pkg.go.dev/go/types#TypeName

The question becomes, is the golang.org/x/tools/go/packages package not loading alias info? What led you to believe that the parser doesn't support alias information?

If it is possible to extract alias names, I would much prefer that solution than having the burden be placed on users to create manual exceptions to type names. I have a suspicion mockery is simply doing something wrong here.

So I might be missing something here, but it does seem to me like the parsing packages Golang provides would indeed be able to differentiate type alias from the underlying type, as shown by my proof of concept in the linked issue. Although I wonder if the issue is that the types.TypeName passed to getPackageScopedType was resolved to the real type farther up the call stack.

The types package clearly understands the difference between alias and types: https://pkg.go.dev/go/types#TypeName

The question becomes, is the golang.org/x/tools/go/packages package not loading alias info? What led you to believe that the parser doesn't support alias information?

If it is possible to extract alias names, I would much prefer that solution than having the burden be placed on users to create manual exceptions to type names. I have a suspicion mockery is simply doing something wrong here.

I looked at the issues of other mock generator and they all have the same problem, see these 2 gomock issues for example:

mockgen should not follow type aliases
Document why a user should choose the source or reflect mode

Looks like they created an alternative "source" mode to parse the source directly to avoid missing this information. I stepped on the code and looked at the object returned to the type alias, I didn't find any mention of the alias anywhere, the same that is said on the first issue above.

So with the current mockery version it is effectivelly impossible to overcome the cloud.google.com/go/pubsub.Message problem, so this is an alternative, as this other implementation will be hard and time-consuming to do.

What I would like to determine before committing to this proposal is what part of the mockery call stack do we lose the alias information? I'm betting that the breakage is happening somewhere in this method:

but I want to confirm for certain that there's nothing we could do here. At the moment it's not clear to me at what point the alias information is lost. I'm sure we could add a bunch of print statements in the code to prove it... it would help my sanity.

What I would like to determine before committing to this proposal is what part of the mockery call stack do we lose the alias information? I'm betting that the breakage is happening somewhere in this method:

mockery/pkg/generator.go

Line 59 in 8641a5b

func (g *Generator) populateImports(ctx context.Context) {

but I want to confirm for certain that there's nothing we could do here. At the moment it's not clear to me at what point the alias information is lost. I'm sure we could add a bunch of print statements in the code to prove it... it would help my sanity.

It is easy to step in the code using this MR to trigger this problem, step into the generator_test.go:TestInternalPackagePrologue function and you can see what happens to the *types.TypeName variable, I looked at it into a debugger and found no way to go back the the alias value itself.

So I might be missing something here, but it does seem to me like the parsing packages Golang provides would indeed be able to differentiate type alias from the underlying type, as shown by my proof of concept in the linked issue.

There's a gap in your proof-of-concept. You're correct in that you can identify a type alias declaration. However, aliases are not preserved in the type graph, so any variables, struct fields, etc. of an alias type are resolved as the aliased type itself and any useful information about the alias itself is discarded and unavailable from those nodes. You can't distinguish between the alias and the type to which it refers when using packages.Load, etc., because the information simply isn't there. This, unfortunately, impacts numerous tools in the Go ecosystem beyond just Mockery.

This is the closest thing to an upstream tracking issue for this problem that I can find: golang/go#44410

I'd love to have the proposed functionality as an option until the Go language itself fixes the underlying issue, and I'm not holding my breath waiting for that to happen.

@wyattanderson that makes more sense. I understand the need for this a little better. It's unfortunate and I really hate having to maintain hacky stuff like this but I can't think of a better solution until the go maintainers fix the parsers (which probably isn't anywhere high on their priority list).

After having given it more thought I think we can go ahead with this. However @RangelReale could you add a section in the mkdocs page here: https://vektra.github.io/mockery/features/ . I am not adding any documentation into the root readme anymore. We can just add another section regarding type aliases and how to resolve it with the feature you've implemented here.

Codecov Report

Patch coverage: 90.38462% and project coverage change: +0.42828 🎉

Comparison is base (c96741b) 74.92926% compared to head (ec95f73) 75.35754%.

@@                 Coverage Diff                 @@
##              master        #540         +/-   ##
===================================================
+ Coverage   74.92926%   75.35754%   +0.42828%     
===================================================
  Files              7           7                 
  Lines           1767        1818         +51     
===================================================
+ Hits            1324        1370         +46     
- Misses           358         362          +4     
- Partials          85          86          +1     

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@LandonTClipp yes I fully agree with you, I hate having to add these kinds of workarounds, but in this case there seems to be absolutely no way around it. I'll look at cleaning up the code and updating the documentation tomorrow.

@wyattanderson @LandonTClipp maybe we can detect that this is an alias and issue a warning about it?

I refactored the parameter parsing to be done only at startup, see if everything is ok.

Great work, I’ll give it a review in the next day or so.

Thank you sir, I'll take another look at this in the next day or so!

Very late to the game but hit this error and I have a problem that this does not solve. I have multiple packages that mockery maps down to a single internal package and I cannot use this parameter to replace back to those packages. So what happens is:

• mockery follows packages A, B, C to internal package Z
• I can use replace-type to map Z to A, or B, or C but not all of them!
  The package that causes this is not mine and I cannot fix it so seem unable to use mockery to mock my interface.

@papadeltasierra thats really tricky. Unfortunately the only way you can get around this is by manually specifying the replacements for each individual type. There is no way mockery can know where your type alias originally came from because historically, a type alias is not represented in the type tree.

There is a lead I'm chasing up in Go 1.22 where we might be able to retain the alias information if you set a specific GODEBUG flag. The Go authors know this is an issue and have made some half attempt at providing a fix.

@LandonTClipp thanks for the info. Currently I've manually "patched" the mockery output and removed this interface from .mockery.yaml. Is there a "very high level for the rest of us" explanation of why mockery even follows down the import trees? Doesn't the signature of the interface functions together with the imports in the interface file tell mockery everything it needs to know?

@papadeltasierra yes the high level explanation is that prior to Go 1.22, the parsed type tree did not have any representation for a type alias. It always got resolved down to the underlying type, so there was no way to extract the alias information. This was a limitation with the Go package parser itself, not with mockery.

You can see in 1.22 they added a types.Alias type that would get returned when gotypelias is set to 1. This is probably the solution moving forward, but we need to add support for this in mockery.

@papadeltasierra update on the gotypelias lead, we will not be able to get support for handling this cleanly until at least Go 1.23 when the Go devs make the requisite changes to golang.org/x/tools/go/packages. See more details here: #763 (comment)